In the field of secure communications for obtaining services over a network, the use of security tokens in communications between an identity provider and a service provider is a known concept. One type of known system is Security Assertion Markup Language (SAML), which is an XML-based standard for exchanging authorization and authentication data between security domains (i.e., between an identity provider (a producer of assertions) and a service provider (a consumer of assertions)). Another type of known system utilizes Kerberos security tokens. In each of these conventional systems, one token is normally created for one service provider/Kerberos service when requested from an identity provider or Key Distribution Center (KDC). The token is normally protected by a signature and/or encryption using a pre-established trust between each service provider/Kerberos service and the identify provider/KDC. This means that the security token can only be consumed by one service provider/Kerberos service.
In a work flow scenario that requires a user to visit multiple service providers, multiple security tokens have to be acquired for each service provider. The multiple tokens have to either be requested by the user, or through some type of delegation and/or federation. The difference between each of these multiple tokens may be just the signature/encryption of each security token, while the Assertion (authorization) part might be the same between these security tokens.
A system to address the foregoing has been proposed in U.S. Patent Publication No. 2003/0126441 (Laux). In the system proposed by Laux, when a user logs-in to access a first service, authentication information for the first service, along with authentication information for a plurality of related services, is provided in a token to the user. Thus, when the user provides the security token to access the first service, if the user also wants to access other related services, the user does not need to provide a separate security token for the related service since it already includes the authentication information for the related services. One problem with this technique is that the security token includes credentials for related services that the user did not request and that the user may not want to use. That is, the user merely requests access to one service, and the system of Laux automatically includes related services under the assumption that the user may want to access the additional related services. While this may address an issue with requiring multiple accesses to the authentication source for separate tokens in order to access multiple services, the system is nonetheless inherently inefficient because it needlessly includes unwanted and unnecessary information.
In generating a security token for conventional systems, typically, the token includes a session key (or information necessary to derive the session key) specific for a particular service provider. In generating the session key (or information to derive the key) to be included in the token, the authentication source generally knows the secret key for each service provider on the network, and uses the secret key to generate the session key (or information to derive the session key). Upon receiving the token, the service provider can retrieve the session key from the token, or can utilize the information in the token to derive the session key so that the device can access the service provider. Thus, a one-to-one token-to-service provider approach is generally used. This also provides for certain inefficiencies because it requires the generation of multiple different session keys for each service provider, which again, results in needless and excessive information being included in the token.